\mysection{Architektur}
\label{real:sec:architektur}
Im ersten Teil werden wir kurz den Ablauf einer Benachrichtigung in \masp und
die dafür notwendigen Komponenten erläutern. Darauf folgt die Vorstellung der
von uns implementierten Klassen.

\mysubsection{Ablauf einer Benachrichtigung in MASP}
\label{real:subsec:ablauf}
In Abbildung \ref{fig:notification_sequence} ist der Prozessablauf für eine
Benachrichtigung in \masp dargestellt. Dabei ist dieser Prozessablauf im
Gegensatz zum ursprünglichen Ablauf bereits für die Integration unseres
Benachrichtigungssystems angepasst worden.
\begin{figure}[htb] \centering
\includegraphics[width=1.0\textwidth]{images/Notification-sequence}
\caption{Prozessdiagramm für Benachrichtigungen in MASP}
\label{fig:notification_sequence}
\end{figure}
Dabei gibt es 6 Komponenten, die sich für verschiedene Bereiche der
Benachrichtigung verantwortlich zeigen. Diese werden wir zuerst kurz im
Einzelnen beschreiben.

\paragraph{Distribution}
\label{real:para:distribution}
Die Aufgabe der \textit{Distribution} ist es, Benachrichtigungen an die
Ausgabegeräte zu verteilen.

\paragraph{Notification Strategy}
\label{real:para:strategy}
Die \textit{Notification Strategy} repräsentiert eine Strategie zur Verteilung
von Benachrichtigungen an die Ausgabegeräte.

\paragraph{MessageCenter}
\label{real:para:messagecenter}
Das \textit{MessageCenter} ist der Unterbau der in Abschnitt
\ref{konzept:sec:nachrichtenzentrale} beschriebenen Nachrichtenzentrale. An die
\textit{MessageCenter}-Komponente werden alle Nachrichten geschickt und dort
auch gespeichert. Dabei existiert für jeden Benutzer ein eigenes
\textit{MessageCenter}. Das Senden von Nachrichten wird dabei jedoch durch eine
statische Methode realisiert und intern an das spezielle \textit{MessageCenter}
des angegebenen Benutzers weitergeleitet.

\paragraph{Application}
\label{real:para:application}
Die \textit{Application} ist die Nachrichtenquelle.

\paragraph{NotificationUI}
\label{real:para:notififcationUI}
Die \textit{NotificationUI} ist für das Initiieren und Verwalten von
Benachrichtigungen zuständig.

\paragraph{Device}
\label{real:para:device}
Das \textit{Device} ist ein Ausgabegerät.
\\\\
Bei der Initialisierung von \masp instanziiert die \textit{Distribution} die
\textit{NotificationStrategy}. Dabei wird der \textit{NotificationStrategy}
auch das Kontextmodell mitgeteilt. Danach erstellt die
\textit{NotificationStrategy} für alle Benutzer-IDs, die sie aus dem
Kontextmodell abfragen kann, jeweils ein \textit{MessageCenter}. Auf jedem
dieser \textit{MessageCenter} registriert die \textit{NotificationStrategy}
einen Observer, um später über neue Nachrichten Bescheid zu wissen. Damit ist
die Initialisierungs-Phase abgeschlossen.
\\
Wenn nun eine \textit{Application} eine Nachricht schicken möchte, gibt es zwei
mögliche Wege. Der erste Weg sieht vor, dass die \textit{Application} dem
\textit{MessageCenter} mittels der send-Methode die Nachricht, ihre eigene ID,
die Benutzer-ID und eine Dringlichkeit übergibt. Diese Variante ist so in
unserem Konzept nicht vorgesehen, wurde jedoch für eine leichtere Anbindung von
existierenden Nachrichtenquellen realisiert. Der zweite Weg zum Versenden einer
Nachricht entspricht dann unserem Konzept. Zuvor muss die \textit{Application}
die zu sendende Nachricht bereits mit der \textit{Application}-ID, einer
Nachrichtenkategorien-ID, dem Nachrichtenkategorien-Namen und einem Mapping
von möglichen Zeiten der Auslieferung zu Dringlichkeiten registriert haben. Dann
kann die \textit{Application} ebenfalls mit der send-Methode eine Nachricht
verschicken. In diesem Fall wird dann jedoch keine Dringlichkeit angegeben,
sondern die Nachrichtenkategorien-ID und der aktuelle Zeitpunkt.
\\
Wenn die Nachricht an das \textit{MessageCenter} übergeben wurde, werden die
zuvor von der \textit{NotificationStrategy} und der \textit{NotificationUI}
registrierten Observer bzw. deren newMessage-Methode mit dem zur Nachricht
gehörenden \textit{Message}-Objekt aufgerufen. Die \textit{NotificationUI} teilt
der \textit{Distribution} nun mit, dass sie eine Benachrichtigung an den
Benutzer ausliefern, also an Ausgabegeräte verteilen soll.
\\
Um zu wissen, an welche Ausgabegeräte die Benachrichtigung gesendet werden muss,
ruft die \textit{Distribution} die \textit{NotificationStrategy} auf. Diese
berechnet nun, welche Ausgabegeräte für welche Formen der Benachrichtigung
genutzt werden. Dabei kann die \textit{NotificationStrategy} den Befehl
zur Berechnung bestimmten Nachrichten zuordnen, da sie zuvor, wie bereits
beschrieben, durch den \textit{MessageCenter}-Observer über neue Nachrichten
informiert wurde. Anhand der Informationen aus dem \textit{Message}-Objekt kann
eine Auswahl der Geräte getroffen werden. Diese Entscheidung wird als
\textit{distributionConfigurations} an die \textit{Distribution} zurückgegeben.
Die \textit{Distribution} sendet die Benachrichtigung nun an die ausgewählten
Ausgabegeräte.
\\
Optional kann eine Benachrichtigung auch verschieden Optionen zur weiteren
Vorgehensweise anbieten, die von der \textit{Application} festgelegt wurden. Die
gewählte Option wird dann an die \textit{NotificationUI} gesendet, welche sie
wiederum an die \textit{Application} weiterleitet.

\mysubsection{Klassen}
\label{real:subsec:klassen}
Nun wollen wir die verschiedenen Klassen vorstellen, die zum Prototypen unseres
Benachrichtigungskonzeptes gehören. Ein Überblick über die von uns
implementierten Klassen in Form eines UML-Klassendiagramms ist in Abbildung
\ref{fig:classDiagramm} zu sehen. Als Einstiegspunkt fungiert hier die
\notStrat. Wir werden die einzelnen Klassen unabhängig voneinander erläutern und
die wichtigen Methoden präsentieren.

\begin{figure}[htb] \centering
\includegraphics[width=1.0\textwidth]{images/NS_class_diagram_small}
\caption{Klassendiagramm}
\label{fig:classDiagramm}
\end{figure}

\mysubsubsection{NotificationStrategy}
\label{real:subsubsec:notificationStrategy}

\begin{figure}[htb] \centering
\includegraphics[width=0.7\textwidth]{images/class_NotificationStrategy}
\caption{\textit{NotificationStrategy}-Klasse}
\label{fig:class_NotificationStrategy}
\end{figure}

Die \notStrat ist eine Implementierung des
\textit{DistributionStrategy}-In"-ter"-faces von \masp. Die Klasse bietet somit
eine Strategie für die Verteilung von Benachrichtigungen an die Ausgabegeräte an.
Dies bedeutet, dass \masp die \notStrat bei einer neuen Benachrichtigung damit
beauftragt, die zu benutzenden Ausgabegeräte zu berechnen. Um dies zu
ermöglichen, dient die \notStrat auch dazu, den weiteren Klassen des
Benachrichtigungssystems das Kontextmodell bereitzustellen. Als innere Klasse
ist hier zusätzlich ein \textit{MessageObserver} implementiert. Dieser hat nur
eine sehr geringe Funktionalität. Deshalb haben wir ihn als innere Klasse
realisiert. Der \textit{MessageObserver} hört nur auf neue Nachrichten und speichert
diese in der \notStrat, um beim Auftrag die Verteilung zu berechnen und die zu
verteilende Benachrichtigung einer Nachricht zuordnen zu können. Auf diese Weise
können weitere Eigenschaften der Nachricht in den Entscheidungsprozess
einfließen, die beim Berechnungsaufruf nicht mit übergeben werden.

\paragraph{setContextConnection(ContextConnection)}
\label{real:para:setCtxCon}
Diese Methode wird nach der Initiierung der \notStrat aufgerufen und dieser so
ein \textit{ContextConnection}-Objekt bekannt gemacht. Die
\textit{ContextConnection}-Klasse bietet verschiedene Funktionen für einen
komfortableren Zugriff auf die Daten des Kontextmodells. In dieser Methode
werden zudem für alle Benutzer je ein \textit{MessageCenter} erstellt und bei jedem
\textit{MessageCenter} ein \textit{MessageObserver} registriert.

\paragraph{setContextModel(Environment)}
\label{real:para:setCtxModel}
Diese Methode wird ebenfalls nach der Initiierung der \notStrat aufgerufen und
mit dem Kontextmodell (\textit{Environment}) bekannt gemacht. Dadurch ist
es möglich, auch Anfragen an das Kontextmodell zu senden, die von der
\textit{ContextConnection} nicht angeboten werden.

\paragraph{calculateDistribution(UserInterfaceMask) : Set}
\label{real:para:calcDistr}
Wenn die Verteilung einer Benachrichtigung berechnet werden soll, muss \masp
diese Methode aufrufen. Dabei wird eine \textit{UserInterfaceMask} übergeben.
Diese enthält die ID der Nachrichtenquelle, die ID des Empfängers sowie eine
Liste von UI-Elementen, aus denen die Benachrichtigung bestehen soll. Anhand der
Quellen-ID und der Empfänger-ID wird nun die Nachricht, die zuvor durch den
\textit{MessageObserver} gespeichert wurde, gefunden. Mit den Daten aus
der \textit{UserInterfaceMask} und der Nachricht wird das
Benachrichtigungssystem beauftragt, die Präsentationsart und eine Liste von
Ausgabe-Ressourcen zu berechnen. Für jedes UI-Element wird ein
\textit{DistributionConfiguration}-Objekt erstellt, das das UI-Element und die
dazugehörige Ausgabe-Ressource enthält. Diese Menge an
\textit{DistributionConfiguration}s wird dann in einem \textit{Set} an \masp
zurückgegeben.
\mysubsubsection{NotificationSystem}
\label{real:subsubsec:notificationSystem}
Das \notSys ist der Controller für den von uns entwickelten Teil eines
Benachrichtigungssystem. Es bietet also Funktionen, um unsere Konzepte zu den
Problematiken Geräteauswahl und Dringlichkeitseinfluss auf die
Prä"-sen"-ta"-tions"-art umzusetzen.
\begin{figure}[htb] \centering
\includegraphics[width=1.0\textwidth]{images/class_NotificationSystem}
\caption{\textit{NotificationSystem}-Klasse}
\label{fig:class_NotificationSystem}
\end{figure}
\paragraph{getInstance() : NotificationSystem}
\label{real:para:getInstNotSys}
Da nur ein Benachrichtigungssystem notwendig ist, ist diese Klasse als Singleton
implementiert. Damit andere Klassen also das einzige existierende \notSys-Objekt
bekommen können, gibt es diese, dem Singleton-Pattern entsprechende, Methode.
Wenn das \notSys noch nicht instanziiert wurde, übernimmt diese Methode diese
Aufgabe.

\paragraph{getSettings() : NotificationSettings}
\label{real:para:getSett}
Die \notSett enthalten die registrierten Nachrichtenkategorien sowie die dazu
gehörigen Standard- und Benutzerdringlichkeiten. Damit andere Klassen, die auf diese Daten
zugreifen möch"-ten, sich nicht selbst um das Laden kümmern müssen, bietet das
\notSys diese Methode an. Das \notSys deserialisiert über die JAXB-API die Daten
aus der XML-Datei und erstellt dadurch das \notSett-Objekt beim ersten Aufruf
der Methode und speichert das Objekt in einer Instanzvariablen. Bei jedem
folgenden Aufruf der getSettings-Methode kann dann das bereits existierende
Objekt zurückgegeben werden. Damit wird sichergestellt, dass alle Klassen immer
auf dem gleichen Objekt arbeiten. Sollte die XML-Datei noch nicht existieren,
wird sie ebenfalls von dieser Methode generiert.

\paragraph{saveSettings()}
\label{real:para:saveSett}
Um die Änderungen am \notSett-Objekt persistent zu speichern, muss diese Methode
aufgerufen werden. Dabei wird das Objekt über die JAXB-API in die XML-Datei
serialisiert. Sollte die XML-Datei noch nicht existieren, wird sie vorher
erstellt.

\paragraph{registerMessage(String, String, String, Map, Map)}
\label{real:para:regMsg}
Wenn Nachrichtenquellen eine Nachrichtenkategorie registrieren wollen, müssen
sie dieser Methode ihre eigene ID, die Kategorien-ID, den Kategorienamen sowie
zwei \textit{Map}s übergeben. Die \textit{Map}s enthalten beide als Schlüssel
die IDs der Benachrichtigungszeitpunkte. Die Werte sind dann bei der ersten
\textit{Map} kurze Beschreibungen des Zeitpunktes, z.B. "`5 Minuten vor dem
Termin"' und bei der zweiten die Standard-Dringlichkeit für den entsprechenden
Zeitpunkt. Dabei werden nur Zeitpunkte und ihre Dringlichkeit gespeichert,
deren ID in beiden \textit{Map}s als Schlüssel vorkommen. Die neue
Nachrichtenkategorie wird dann im \notSett-Objekt gespeichert. Sollte zu einer
Kombination von Quellen-ID und Kategorien-ID bereits eine Kategorie registriert
sein, so wird die alte Kategorie überschrieben. Damit ist dies auch der Weg, um
bestehende Kategorien zu aktualisieren. Dabei ist jedoch zu beachten, dass die
Nachrichtenquelle erneut alle Daten übergeben muss, da die alten Werte komplett
gelöscht werden.

\paragraph{saveUserUrgency(String, String, String, String, int)}
\label{real:para:saveUrgency}
Um das Feedback eines Benutzers bzgl. seiner persönlichen Dringlichkeit einer
Benachrichtigung zu speichern, übergibt man dieser Methode die entsprechende
Benutzer-ID, die Quellen- und Kategorien-ID. Somit ist es möglich, die richtige
Kategorie zu identifizieren sowie die Zeitpunkt-ID und die zu speichernde
Dringlichkeit. Bereits existierende Dringlichkeiten  für den angegebenen
Zeitpunkt der angegebenen Kategorie werden überschrieben.

\paragraph{calculatePresentation(String, String, String, String, int,
ContextConnection) : List}
\label{real:para:calcRsrcs}
Um die Präsentationsart und die Ausgabe-Ressourcen für eine Benachrichtigung zu
bestimmen, werden dieser Methode die Quellen-ID, die Kategorien-ID, die
Benutzer-ID des Empfängers, die ID des Zeitpunktes der Benachrichtigung, eine
Dringlichkeit und die \ctxCon übergeben. Die Dringlichkeit dient hierbei dafür,
um auch vorher nicht registrierte Nachrichtenkategorien bearbeiten zu können.
Bei solchen Kategorien braucht die Quelle keine Kategorien-ID und keinen
Zeitpunkt angeben, muss jedoch eine Dringlichkeit für die aktuelle
Benachrichtigung mitliefern. Für registrierte Nachrichtenkategorien wird eine
Angabe der Dringlichkeit einfach ignoriert, da die registrierten Dringlichkeiten
über die Kategorien- und Zeitpunkt-IDs ermittelt werden. Die \ctxCon wird
übergeben, da der \devDec sie später für seine Entscheidung benötigt. Diese
Methode beauftragt dann mit den übergebenen Parametern die \decEng mit der
Berechnung der Präsentationsart und der Ausgabe-Ressourcen. Sofern eine
Dringlichkeit angegeben ist, diese jedoch außerhalb des zugelassenen Bereichs
von 1 bis 5 liegt, wird der Wert nach oben oder unten korrigiert.

\mysubsubsection{NotificationSettings}
\label{real:subsubsec:notificationSetting}
Die \notSett-Klasse ist die Java-Repräsentation der in einer XML-Datei
gespeicherten Nachrichtenkategorien und der dazugehörenden Standard- und
Benutzerdringlichkeiten.
\begin{figure}[htb] \centering
\includegraphics[width=0.7\textwidth]{images/class_NotificationSettings}
\caption{\textit{NotificationSettings}-Klasse}
\label{fig:class_NotificationSettings}
\end{figure}
Über die JAXB-API wird die XML-Datei deserialisiert und
so ein \notSett-Objekt erstellt. Zum persistenten Speichern der Daten im
\notSett-Objekt, vor allem wenn bestehende geändert oder neue hinzugefügt
wurden, dient erneut die JAXB-API zum Serialisieren. In der \notSett-Klasse gibt
es zwei Instanzvariablen, \textit{messageCategories} und \textit{users}. Erstere
enthält ein Mapping von IDs, die aus Quellen-ID und Kategorien-ID
zusammengesetzt sind, zu \textit{MessageCategory}-Objekten. Diese interne Klasse
repräsentiert eine registrierte Nachrichtenkategorie inklusive einer Liste von
\textit{TimeOfNotification}-Objekten. Ein Objekt dieser ebenfalls inneren Klasse
repräsentiert einen möglichen Zeitpunkt für eine Benachrichtigung und dessen
Dringlichkeit. Die Liste von \textit{TimeOfNotification}-Objekte in einem
\textit{MessageCategory}-Objekt enthält alle Zeitpunkte einer registrierten
Nachricht, inklusive der Standard-Dringlichkeit.
\\
Die Benutzer-Dringlichkeiten sind wiederum in der Instanzvariablen
\textit{users} zu finden. Dies ist ein Mapping von Benutzer-IDs zu Objekten der
inneren Klasse \textit{User}. Ein Objekt dieser Klasse enthält ebenfalls eine
Variable \textit{messageCategories}, die das gleiche Mapping wie die
namensgleiche Variable in \notSett darstellt. Hier enthält das Mapping jedoch
nur solche Nachrichtenkategorien, zu denen der Benutzer bereits persönliche
Dringlichkeiten angegeben hat. Dabei werden zudem neue Objekte erzeugt und
nicht die bereits vorhandenen \textit{MessageCategory}-Objekte aus der \notSett
eigenen \textit{messageCategories}-Variablen benutzt. Die in diesen
\textit{MessageCategory}-Objekten enthaltenen
\textit{TimeOfNotification}-Objekte repräsentieren die Zeitpunkte, zu denen der
Benutzer eine Dringlichkeit angegeben hat. Diese persönliche Dringlichkeit ist
dann auch in diesen \textit{TimeOfNotification}-Objekten gespeichert. Hierwerden natürlich ebenfalls neue \textit{TimeOfNotification}-Objekte erstellt, dadiese nur eine Dringlichkeit haben können.

\paragraph{getMessageCategories() : List}
\label{real:para:getMsgCats}
Diese Methode gibt eine Liste aller \textit{MessageCategory}-Objekte in der
\textit{messageCategories}-Map zurück. Die \textit{User}-Klasse hat eine
gleich benannte Methode mit einer analogen Funktionalität, wodurch die
Nachrichtenkategorien mit persönlichen Dringlichkeiten abgefragt werden können.
Diese Methode wird hauptsächlich von der JAXB-API benutzt, um das
\notSett-Objekt zu serialisieren.

\paragraph{setMessageCategories(List)}
\label{real:para:setMsgCats}
Diese Methode erhält eine Liste von \textit{MessageCategory}-Objekten, wandelt
diese in eine \textit{Map} um und weist diese der
\textit{messageCategories}-Variable zu. Dadurch wird eine etwaige vorhandene
\textit{Map} gelöscht. Die \textit{User}-Klasse hat eine gleich benannte Methode
mit einer analogen Funktionalität, wodurch dem Benutzer Nachrichtenkategorien
mit persönlichen Dringlichkeiten zugewiesen werden. Diese Methode wird
hauptsächlich von der JAXB-API benutzt, um das \notSett-Objekt zu
deserialisieren.

\paragraph{getUsers() : List}
\label{real:para:getUsers}
Diese Methode gibt eine Liste aller \textit{User}-Objekten in der
\textit{user}-Map zurück. Diese Methode wird hauptsächlich von der JAXB-API
benutzt, um das \notSett-Objekt zu serialisieren.

\paragraph{setUsers(List)}
\label{real:para:setUsers}
Diese Methode erhält eine Liste von \textit{User}-Objekten, wandelt diese in
eine \textit{Map} um und weist diese der \textit{users}-Variable zu. Dadurch
wird eine etwaige vorhandene \textit{Map} gelöscht. Diese Methode wird
hauptsächlich von der JAXB-API benutzt, um das \notSett-Objekt zu
deserialisieren.

\paragraph{addMessageCategory(MessageCategory)}
\label{real:para:addMsgCat}
Fügt der \textit{messageCategories}-\\Map das übergebene
\textit{MessageCategory}-Objekt hinzu. Wenn bereits eine
\textit{MessageCategory} mit der gleichen ID existiert, wird diese
überschrieben.

\paragraph{addUserUrgency(String, String, String, int)}
\label{real:para:addUserUrgency}
Dem \textit{User}-Objekt mit der übergebenen Benutzer-ID wird eine neue
persönliche Dringlichkeit übergeben. Dazu wird die Kombination von Quellen- und
Kategorien-ID und der Zeitpunkt, für die die Dringlichkeit gilt, übergeben
sowie die neue Dringlichkeit. Bestehende Dringlichkeiten für die angegebene
Nachrichtenkategorie und den Zeitpunkt werden überschrieben.

\paragraph{getDefaultUrgency(String, String)}
\label{real:para:getDefaultUrgency}
Um die von der Nachrichtenquelle bei der Registrierung angegebene
Standard-Dringlichkeit zu erhalten, ruft man diese Methode mit der Kombination
aus Quell- und Kategorien-ID sowie der ID des Zeitpunktes auf. Anhand der
ID-Kombination kann die richtige Kategorie in der
\textit{messageCategories}-Map gefunden werden. Im so ermittelten
\textit{MessageCategory}-Objekt wird mit der Zeitpunkt-ID das zugehörige
\textit{TimeOfNotification}-Objekt ermittelt und so die Standard-Dringlichkeit
gefunden. Wenn keine Dringlichkeit gefunden werden kann, wird ein
allgemeiner Standardwert zurückgegeben.

\paragraph{getUserUrgency(String, String, String)}
\label{real:para:getUserUrgency}
Diese Methode ermittelt die Benutzerdringlichkeit analog zur
getDefaultUrgency-Methode. Der einzige Unterschied besteht darin, dass mit der
übergebenen Benutzer-ID zuerst das entsprechende \textit{User}-Objekt
ermittelt wird und die weitere Suche auf der \textit{messageCategories}-Map
dieses Objektes durchgeführt wird. Wenn keine Dringlichkeit gefunden werden
kann, wird 0 zurückgegeben. Somit wird gezeigt, dass für die angegebene
Nachrichtenkategorie und den angegebenen Zeitpunkt keine Benutzerdringlichkeit
vorhanden ist.

\mysubsubsection{DecisionEngine}
\label{real:subsubsec:decisionEngine}
Die \decEng fungiert als Controller-Klasse der Entscheidungsengine. Sie wird
aufgerufen, um über die Art und Ausgabegeräte der Benachrichtigung zu
entscheiden.
\begin{figure}[htb] \centering
\includegraphics[width=1.0\textwidth]{images/class_DecisionEngine}
\caption{\textit{DecisionEngine}-Klasse}
\label{fig:class_DecisionEngine}
\end{figure}
Sie ist ebenfalls als Singleton implementiert. Eine genauere
Erklärung der getInstance-Methode lassen
wir aus, da die Funktion sehr trivial ist und zudem in Abschnitt
\ref{real:subsubsec:notificationSystem} bereits analog erklärt wurde.

\paragraph{descidePresentation(String, String, String, int, ContextConnection) :
List}
\label{real:para:descidePresentation}
Dies ist die einzige Methode der \decEng. Sie erhält immer die bereits
konkatenierten Quell- und Nachrichtenkategorien-IDs, die Benutzer-ID des
Empfängers und die \ctxCon. Von den beiden weiteren Parameter, die ID des
Zeitpunktes und die Dringlichkeit, wird nur eins benötigt. Wenn die
Nachrichtenkategorie registriert wurde, reicht die Zeitpunkt-ID. Ansonsten wird
eine Dringlichkeit übergeben, die für die weitere Entscheidung benutzt werden
soll. Die Methode ruft dann die einzelnen Entscheider auf. Dies sind gemäß
unseres Konzeptes der \presDec und der \devDec. Dabei wird das Ergebnis des
\presDec an den \devDec übergeben, da dessen Entscheidung darauf basiert. Aus
den Ergebnissen der beiden Entscheider fasst diese Methode die
Gesamtentscheidung über die Präsentationsart und -geräte
in einem \decRes-Objekt zusammen und gibt dieses zurück.

\mysubsubsection{DecisionResult}
\label{real:subsubsec:decisionResult}
Die \decRes-Klasse dient nur der Aggregation von Präsentationsart und
der Liste von Ausgabe-Ressourcen in einem Objekt, um diese beiden Bestandteile
einer Präsentationsentscheidung zusammen an die aufrufenden Klassen
zu"-rück"-zu"-ge"-ben.
\begin{figure}[htb] \centering
\includegraphics[width=0.4\textwidth]{images/class_DecisionResult}
\caption{\textit{DecisionResult}-Klasse}
\label{fig:class_DecisionResult}
\end{figure}
Da eine solche Entscheidung von anderen Klassen nicht verändert
werden soll, bietet die \decRes-Klasse lediglich getter-Methoden auf die beiden
Bestandteile der Entscheidung an.

\mysubsubsection{PresentationDecider}
\label{real:subsubsec:presentationDecider}
Der \presDec entscheidet über die Präsentationsart der Benachrichtigung. Genauer
gesagt, ermittelt er die Präsentationsstufe für die Dringlichkeit einer
Nachricht.
\begin{figure}[htb] \centering
\includegraphics[width=1.0\textwidth]{images/class_PresentationDecider}
\caption{\textit{PresentationDecider}-Klasse}
\label{fig:class_PresentationDecider}
\end{figure}
Die eigentliche Programmlogik berechnet hier jedoch nur die
Dringlichkeit einer Benachrichtigung. In der Instanz-Variablen
\textit{urgencyPresentationModeMap} sind die Präsentationsstufen gespeichert,
wobei jede Stufe einer Dringlichkeit zugeordnet ist. Implementiert wurde dies
als \textit{int}-Array, wobei die Präsentationsstufe für eine Dringlichkeit $d$
dem Index $d-1$ zugewiesen ist. Aufgrund unserer Ergebnisse des Fragebogens(s.
Abschnitt \ref{konzept:subsubsec:auswertung_des_fragebogen}) entspricht die
Dringlichkeit auch der Präsentationsstufe. Um jedoch den Dringlichkeiten später
andere Präsentationsstufen einfacher zuordnen zu können, die z.B. durch
abweichende Ergebnisse in späteren Untersuchungen auftreten können, wurde eine
Instanz-Variable als Realisierung der Zuordnung gewählt, anstatt die Dringlichkeit einfach als
Präsentationsstufe zu verwenden. Zudem wurden die hier aufgeführten Methoden
sowie der Konstruktor als \textit{protected} deklariert. Dies wird damit
begründet, dass der \presDec lediglich von der \decEng aufgerufen werden soll.
Da beide Klassen im gleichen Paket liegen, können wir den Zugriff so
beschränken.

\paragraph{getPresentationMode(String, String, String, int) : int}
\label{real:para:getPresentationMode}
Die Methode gibt die Präsentationsstufe zurück, wobei dazu zuvor die
Dringlichkeit bestimmt wird. Für diese Bestimmung wird der angepasste
Algorithmus aus Abschnitt \ref{konzept:subsubsec:ergebnis_des_fragebogens}
benutzt. Als Parameter bekommt die Methode eine Benutzer-ID, die konkatenierte
Quell- und Nachrichtenkategorien-ID, die ID des Benachrichtigungszeitpunktes und
eine Dringlichkeit. Eines der letzten beiden Parameter darf leer, bzw. 0, oder
\textit{null} sein. Sollte die Zeitpunkt-ID nicht leer sein, so nehmen wir an,
dass die Nachrichtenkategorie registriert wurde und suchen in den \notSett nach
der Standard-Dringlichkeit für den angegebenen Zeitpunkt dieser
Nachrichtenkategorie. Andernfalls dient die angegebene Dringlichkeit als
Standard-Dringlichkeit. Danach wird die Benutzer-Dringlichkeit für die
Nachrichtenkategorie zu dem angegebenen Zeitpunkt ermittelt. Diese kann auch 0
sein, sofern der Benutzer noch keine persönliche Dringlichkeit angegeben hat
oder die Nachrichtenkategorie nicht registriert wurde. Um die zur Ermittlung der
Präsentationsstufe zu benutzende Dringlichkeit zu erhalten, wird nun überprüft,
ob die Benutzer-Dringlichkeit 0 ist. Sollte dies nicht der Fall sein, wird die
Benutzer-Dringlichkeit verwendet. Ansonsten wird die Standard-Dringlichkeit
verwendet. Sollte diese 0 oder \textit{null} sein, dann wird ein Standard-Wert
genommen. Dieser Fall kann aber nur eintreten, wenn keine Zeitpunkt-ID und keine
Dringlichkeit als Parameter übergeben wurde. Mit der nun ermittelten
Dringlichkeit wird aus der \textit{urgencyPresentationModeMap} die zugehörige
Präsentationsstufe geholt und als Rückgabewert der Methode benutzt.

\mysubsubsection{DeviceDecider}
\label{real:subsubsec:devicedecider}
Der \devDec ist Teil des Paketes \textit{org.sercho.masp.notification.decision}
und bestimmt die zu verwendenden Ausgabegeräte. Diese Klasse wird von der
\decEng instanziiert, welche alle Entscheidungen bezüglich des
Benachrichtigungssystems, das wir implementieren, koordiniert.
\begin{figure}[htb] \centering
\includegraphics[width=0.7\textwidth]{images/class_DeviceDecider}
\caption{\textit{DeviceDecider}-Klasse}
\label{fig:class_DeviceDecider}
\end{figure}
Die Klasse \devDec bestimmt die zu nutzenden \textit{InteractionResource}s.
\textit{InteractionResource}s sind Teile von Geräten, welche der Interaktion mit
dem Benutzer dienen. Eine \textit{InteractionResource} kann eine Ressource sein um
Eingaben anzunehmen oder dem Benutzer Sachen wiederzugeben. Die
Wiedergabemöglichkeiten beschränken sich hier auf die Klasse \textit{Display}
und \textit{Loudspeaker}. Genau wie im \presDec haben wir alle hier aufgeführten
Methoden und den Konstruktor als \textit{protected} deklariert, damit diese zwar
für die \decEng, aber nicht für andere, außerhalb des Paketes liegende Klassen
sichtbar sind.

\paragraph{getNotificationDevices(ContextConnection, String, int) : List}
Diese Methode ist die einzige dieser Klasse, welche für die \decEng sichtbar
ist. Ihr wird der Kontext(\ctxCon), der Benutzername in Form eines
\textit{String} und ein \textit{int} übergeben. Der \textit{int} Parameter
stellt die Stufe der Präsentationsart dar. Zurückgegeben wird eine Liste von
\textit{InteractionResource}s, die zur Benachrichtigung des Benutzers verwendet
werden sollen.
\\
Als Erstes müssen wir uns die verfügbaren Interaktions-Ressourcen geben lassen.
Dies geschieht über die \textit{ContextConnection}. Mithilfe des Benutzernamens
holen wir uns die verfügbaren Interaktions-Ressourcen in der Umgebung des
Benutzers. Für die erste Stufe von Präsentationsarten geben wir \textit{null}
zurück, weil für diese Präsentationsart keine Benachrichtigung vorgesehen ist.
\\
Für die Präsentationsarten 2 und 3 benötigen wir ein visuelles Gerät im
peripheren Sichtbereich. Da wir laut Konzept
(\ref{konzept:subsec:auswahlalgorithmus}) auf ein akustisches Gerät ausweichen,
falls wir kein geeignetes visuelles Gerät im Sichtbereich des Benutzers finden,
erstellen wir neben einer Liste von visuellen Geräten auch eine mit akustischen.
Jetzt bestimmen wir, welche Bildschirme sich im zentralen und welche im
peripheren Sichtbereich befinden. Da wir die Position und die Ausrichtung von
Benutzer und Bildschirm wissen, lässt sich dies über eine Winkelberechnung der
Ausrichtungs- und Abstandsvektoren lösen. Wie dies im Detail geschieht, haben
wir bereits in Abschnitt \ref{real:sec:sichtbereich} erläutert. Wurde ein
Bildschirm im peripheren Sichtbereich gefunden, so wird dieser am Ende der
Methode zurückgeliefert. Falls kein Bildschirm im peripheren Sichtbereich
gefunden wurde, wird auf einen im zentralen Sichtbereich zurückgegriffen. Ist
gar kein Bildschirm im Sichtbereich des Benutzers zu finden, so wird ein akustisches
Gerät gesucht. Wurden mehrere Geräte gefunden, so wird anschließend bestimmt,
welches Gerät sich am nächsten zum Benutzer befindet.
\\
Bei den Präsentationsarten 4 und 5 muss eine zentrale visuelle und eine
akustische Ressource bestimmt werden. Als Prämisse gilt, dass versucht werden
muss, ein Gerät zu finden, welches beide Ressourcen vereint (z.B. ein
Fernseher). Wird kein Gerät gefunden, das eine visuelle Ressource im zentralen Sichtbereich
besitzt, wird versucht ein Gerät mit einer visuellen Ressource im peripheren
Sichtbereich zu finden. Ist kein Gerät zu finden, welches beide Ressourcen
bietet, versuchen wir, Geräte zu finden, welche die Ressourcen einzeln bieten.
Eine visuelle Ressource im zentralen Sichtbereich wird auch hier wieder einer
im peripheren vorgezogen. Zum Schluss werden die gefundenen Geräte bzw.
einzelnen Ressourcen nach der Entfernung zum Benutzer sortiert. Wie auch schon
bei den Präsentationsarten 2 und 3 wird laut Konzept das Gerät gewählt,
welches dem Benutzer am nächsten ist.

\mysubsubsection{NotificationDevice}
\label{real:subsubsec:notificationdevice}
Die \textit{NotificationDevice}-Klasse(Abbildung
\ref{fig:class_NotificationDevice}) ist eine Hilfsklasse für den \devDec. Dieser
muss für die Präsentationsarten 4 und 5 Geräte mit akustischen und visuellen
Ressourcen finden. \begin{figure}[htb] \centering
\includegraphics[width=0.7\textwidth]{images/class_NotificationDevice}
\caption{\textit{NotificationDevice}-Klasse}
\label{fig:class_NotificationDevice}
\end{figure}
Die in \masp existierende \textit{Device}-Klasse wäre dafür ungeeignet, da sie
nicht nur die gewählten Ressourcen beinhaltet, sondern alle, die zu dem
entsprechenden Gerät gehören. Würde der \devDec also die \textit{Device}-Klasse,
zu der die gewählten Ressourcen gehören, zurückgeben, hätten man unter Umständen
keine Möglichkeit, die wirklich gewählten Ressourcen herauszufinden. Deswegen
benutzen wir diese Hilfsklasse, um die gewählten Ressourcen trotzdem in einem
Objekt bündeln zu können, wenn die Ressourcen zum gleichen Gerät gehören.